Auto Detecting Shared Libraries and Creating A Virtual Scope Repository

ABSTRACT

Provided are techniques for receiving a request to load a first resource corresponding to an application into a computing system for execution; determining, whether or not the first resource is identical to a resource loaded in a virtual scope library (VSR); and, if the first resource is determined not to be identical to any particular resource loaded in the VSR, load the first resource into the VSR: and direct references to the first, resource in the application to the first resource loaded in the VSR; and otherwise, if the first resource is determined to be identical to the second resource, direct references to the first resource in the application to the particular resource stored in the VSR.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a continuation and claims the benefit of thefiling date of an application entitled, “Auto Detecting Shared Librariesand Creating a Virtual Scope Repository” Ser. No. 13/538,707, filed Jun.29, 2012, assigned to the assignee of the present application, andherein incorporated by reference.

FIELD OF DISCLOSURE

The claimed subject matter relates generally to techniques for improvingmemory and computational efficiency and, more specifically, to detectingshared libraries and creating a virtual scope repository (VSR) toeliminate duplicate typo registration to optimize system performance andmemory utilization.

SUMMARY

Provided are techniques for improving memory and computationalefficiency by detecting shared libraries and creating a VSR to eliminateduplicate type registration and optimize system performance and memoryutilization, all without modification to existing applications. Incomputer server environments, distinct application packages are oftenpackaged with duplicated libraries or jar tiles. In this case, distinctapplications independently access objects from these duplicatedlibraries via independent class loader scopes.

Currently, to optimize server performance and memory footprint whenthere is a duplicated library, the library is removed from theapplications, repackaged as a single library and installed into theserver environment as a shared library. Then, the applications arereconfigured to use the newly defined shared library. However, thissolution that requires application repackaging is not always possiblesuch as when the applications are vendor-supplied. Such an approach mayalso be expensive, time-consuming and require revalidation and testingof the affected applications.

Provided are techniques for receiving a request to load a first resourcecorresponding to an application onto a computing system for execution;determining whether or not the first resource is identical to a resourceloaded in a virtual scope library (VSR); and, if the first resource isdetermined not to be identical to any particular resource loaded in theVSR, load the first resource into the VSR; and direct references to thefirst resource in the application to the first resource loaded in theVSR; and otherwise, if the first resource is determined to be identicalto the second resource, direct references to the first resource in theapplication to the particular resource stored in the VSR.

This summary is not intended as a comprehensive description of theclaimed subject matter but, rather, is intended to provide a briefoverview of some of the functionality associated therewith. Othersystems, methods, functionality, features and advantages of the claimedsubject matter will be or will become apparent to one with skill in theart upon examination of the following figures and detailed description.

DESCRIPTION OF THE DRAWINGS

A better understanding of the claimed subject matter can be obtainedwhen the following, detailed description of the disclosed embodiments isconsidered in conjunction with the following figures, in which:

FIG. 1 is an example of a computing system architecture that mayimplement the claimed subject matter.

FIG. 2 is a block diagram of an example of an augmented class loader(ACL) first introduced in FEC. I that may implement aspects of theclaimed subject matter.

FIG. 3 is a block diagram of several applications, including scopes, andtheir relationship with a virtual scope library (VSR) implemented inaccordance with the claimed subject matter.

FIG. 4 is a flowchart of a “Load Library” process that may implementaspects of the claimed subject matter.

FIG. 5 is a flowchart of a “Stop Application” process that may implementaspects of the claimed subject matter.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may heutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may he any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can he implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational actions to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

Turning now to the figures, FIG. 1 is a block diagram of an example of acomputing system architecture 100 that may incorporate the claimedsubject matter. A computing system 102 includes a central processingunit (CPU) 104, coupled to a monitor 106, a keyboard 108 and a pointingdevice, or “mouse,” 110, which together facilitate human interactionwith architecture 190 and computing system 102. Also included incomputing system 102 and attached to CPU 104 is a computer-readablestorage medium (CRSM) 112, which may either be incorporated intocomputing system 102 i.e. an internal device, or attached externally toCPU 104 by means of various, commonly available connection devices suchas but not limited to, a universal serial bus (USB) port (not shown) orwirelessly.

CRSM 112 is illustrated storing logic associated with an operatingsystem (OS) 114, a runtime execution server (RES) 116 and two (2)computer software applications, i.e., an application_A 118 and anapplication_B 120. RES 116 incorporates an augmented class loader (ACL)122, which in this example implements functionality associated with theclaimed subject matter in addition to functionality associated with atypical class loader. The functionality of ACL 122 is described in moredetail below in conjunction with FIGS. 2-5.

Application_A 118 includes two (2) libraries, a library_(—)1 124 and alibrary_(—)2 128. Library_(—)1 includes a type definition, i.e. TD_(—)1126. Libraries 124, 128 and included components are used as examplesthroughout the remainder of the Description. It should be noted that atypical computing system might include more than two (2) applicationsand a typical application might include more than two libraries, each ofwhich might include more than one type definition but for the sake ofsimplicity only two applications, two libraries and one type definitionare shown. Application_B 120 also includes library_(—)1 124 and TD_(—)1126. In other words, both applications 118 and 120 include identicalinstantiations, or copies, of library_(—)1 124 and TD_(—)1 126.

Computing system 102 and CPU 104 are connected to the Internet 130,which is also connected to a server computer 132. Although in thisexample, computing system 102 and server 132 are communicatively coupledvia the Internet 139, they could also be coupled through any number ofcommunication mediums such as, but not limited to, a local area network(LAN) (not shown). Further, it should be noted there are many possiblecomputing system configurations, of which computing system architecture100 is only one simple example.

FIG. 2 is a block diagram of ACL 122, introduced above in FIG. 1, ingreater detail. ACL 122 is one simple example of logic that mayimplement the claimed subject matter. One with skill in the relevantarts should be able to designing alternative logic for implementing theclaimed subject matter. ACL 122 includes an input/output (I/O) module140, a data module 142, a library detector 144, a bash generator 146, acomparison module 148 and a load module 150. For the sake of thefollowing examples, logic associated with ACL 122 is assumed to executeon one or more processors (not shown) of computing system 102 (FIG. 1)and stored in CRSM 112 (FIG. 1). It should be understood that theclaimed subject matter can be implemented in many types of computingsystems and data storage structures but, for the sake of simplicity, isdescribed only in terms of computing system 102 and architecture 100(FIG. 1). Further, the representation of ACL 122 in FIG. 2 is a logicalmodel. In other words, components 140, 142, 144, 146, 148 and 150 may bestored in the same or separates files and loaded and/or executed withinarchitecture 100 either as a single system or as separate processesinteracting via any available inter process communication (IPC)techniques.

I/O module 140 handles any communication ACL 122 has with othercomponents of architecture 100 and computing system 102. Data module 142is a data repository for information and parameters that ACL 122requires during initialization and normal operation. Examples of thetypes of information stored in data module 142 include a virtual scoperepository (VSR) 152 and option data 154.

It should be noted that although VSR 152 is illustrated as part of ACL122, it is equally likely that VSR 152 might be implemented as a tile ordatabase stored seperately. VSR 152 includes library reference counts158, a hash library 160 and virtual libraries 162. Library referencecounts 158 stores information on particular virtual libraries in virtuallibraries 162 (see 192, 194, FIG. 3), specifically the number ofapplications current sharing a particular virtual library. In thismanner, a particular library that is no longer in use by any applicationcan be removed from VSR 122. In the alternative, rather than relyingupon a count associated with each library loaded to determine whether ornot a library is currently in use 152, logic may make use of referencesto the applications associated with each library (see 260, 262 and 264,FIG. 5).

Hash library 160 stores hash values, or “codes,” (see 144), each hashcode corresponding to a particular virtual library stored in virtuallibraries 162. In conjunction with each stored hash code, areindications of the particular applications associated with the librariesthat correspond to the hash codes. The use of hash codes stored in hashlibrary 160 is explained below in conjunction with hash generator 144.It should be understood that in this example hash codes are employed toidentify identical libraries but that one with skill in the relevantarts would be able to design other methods of performing the samefunction.

Option data 154 includes information on various user and administrativepreferences that have been set. For example, a user may selectivelyspecify on a library-by-library and/or application-by-application basisthat particular libraries and applications are handled normally ratherthan in accordance with the disclosed technology.

Library detector 144 determines whether not an application being loadedby ACL 122 includes any libraries. If so, hash generator 146 generatesand stores in hash library 160, as hash value, or code, for each libraryencountered during the loading of an application. In this manner, ACL122 can detect a library that is identical to a library that haspreviously been loaded by another application.

For example, if ACL 122 loads application_A 118, a hash value forlibrary 124 is generated. Comparison module 148 compares the generatedhash code to those stored in bash library 160. If the generated hashcode is not found, the hash code is stored in hash library 160 and thecorresponding library, which in this example is library_(—)1 124, isloaded into virtual libraries 162 as a virtually stored library, orLIB_(—)1 VS (see 192, FIG. 3). If ACL 122 subsequently receives arequest to load library_(—)1 124 within application_B 120, a hash codefor library_(—)1 124 is generated and compared to the values stored inhash library 160. This time, comparison module 148 detects a match andrather than loading library_(—)1 124 a second time, application_B 120 isprovided a reference to LIB_(—)1 VS 192 stored in virtual libraries 162.

Load module 150 provides typical class loading services, subject to thedeterminations of loading or not loading any particular library inaccordance with the claimed subject matter. Functionality associatedwith components 142, 144, 146, 148, 150, 152, 154, 156, 158, 160 and 162are described in more detail below in conjunction with FIGS. 3-5.

FIG. 3 is a block diagram of several applications, i.e. application_A118 (FIG. 1). Application_B 120 (FIG. 1) and an application_C 162.Applications 118, 120 and 164 are illustrated with their relativescopes, i.e. an app_A scope 182, an app_B scope 184 and an app_C scope186, respectively.

The scope of application_A 118, i.e. app _A scope 182, includeslibrary_(—)1 124 (FIG. 1), which includes type definition TD_(—)1 126(FIG. 1), library_(—)2 128 (FIG. 1), which includes a type definitionTD_(—)2 166, and an artifact, i.e. a mod_A.xsd 172. The scope ofapplication_B 120, i.e. app_B scope 184, includes library_(—)1 124,which includes type definition TD_(—)1 126 and an artifact, i.e. amod_A.xsd 174. Although artifacts 172 and 174 have the same name andcontent, they are not shared by applications 118 and 120. In otherwords, artifact 172 is not visible to application_B 120 and artifact 174is not visible to application_A 118. The scope of application_C 164,i.e. app_C scope 186, includes library_(—)2 128, which includes typedefinition TD_(—)2 166 and an artifact, i.e. a mod_C.xsd 176.Application scopes 182, 184 and 186 are used as examples in thefollowing description.

In this example library_(—)1 124, including TD_(—)1 126 in both app_Ascope 182 and App_B scope 184 point to, or reference lib_(—)1 VS 192,which is stored in VSR 152 (FIGS. 1 and 2). In a similar fashion,library_(—)2 128, including TD_(—)2 164, reference lib_(—)2 VS 194 inVSR 152. En this manner, the claimed subject matter enablesapplication_A 118 and Application_B 120 to share a single librarylib_(—)1 VS 192 rather than necessitating that each have a copy oflibrary_(—)1 124 as in FIG. 1. Likewise, application_A 118 andapplication_C 162 are able to share lib_(—)2 VS 192 rather thanmaintaining duplicate copies of library_(—)2 128.

FIG. 4 is a flowchart of a “Load Library” process 200 that may implementaspects of the claimed subject matter. In this example, logic associatedwith process 200 is stored on CRSM 112 (FIG. 1) in conjunction with ACL122 (FIGS. 1 and 2) and is executed on one or more processors (notshown) of CPU 104 (FIG. 1) and computing system 102 (FIG. 1).

Process 200 starts in a “Begin Load Library” block 202 and proceedsimmediately to a “Receive Load Request” block 204. During processingassociate with block 204, a request is received to load either alibrary, such as library_(—)1 124 (FIGS. 1 and 3) and library₂2 128(FIGS. 1 and 3), or an artifact that is associated with a library, suchas TD_(—)1 126 (FIGS. 1 and 3) and TD_(—)2 166 (FIG. 3). A library orartifact may be loaded when an application, such as application_A 118(FIGS. 1 and 3), application_B 120 (FIGS. 1 and 3) and application_C 164(FIG. 3), is either loaded or requests that the library or artifact beloaded or loaded when first referenced within an application. In otherwords, libraries may be loaded on an application-by-application orlibrary-by-library basis.

In the scenario in which an artifact is loaded, the library associatedwith the artifact is also typically loaded. In current technology, anapplication that needs a particular artifact would request that theartifact be loaded. RES 116 (FIG. 1) would find the library in which theartifact resides and load the library into the application's scope. Ifas second application then requests the same library, RES 116 would loadfind and load the same library into the second application's scope,resulting in two distinct copies of the library and the artifact inmemory. The disclosed technology, as explained below, addresses thisissue.

During processing associated with block an “App Excluded?” block 206, adetermination is made as to whether or not the application thatrequested the library or artifact be loaded is an “excluded”application,” i.e. an application that an administrator has indicatedshould maintain all referenced libraries within its own scope. (see 154,FIG. 2). If so, control proceeds to a “Load Library” block 208. Duringprocessing, associated with block 208, the library being loaded isloaded in a normal fashion, i.e., all included libraries are loadedwithin the scope of the requesting application.

If during processing associated with block 206 a determination is madethat the requesting application is not an “excluded” application,control proceeds to a “Library (Lib.) Excluded?” block 210. Duringprocessing associated with block 210, a determination is made as towhether or not the library for which a load request has been receivedduring processing associated with block 204 is an “excluded” library,i.e., a library that an administrator has indicated should remain in thescope of the requesting application, (see 154, FIG. 2). If so, controlproceeds to “Load Library” block 208 and the library is loaded asexplained above.

If, during processing associated with block 210, a determination is madethat the library for which a load request has been received has not beendesignated as “excluded,” control proceeds to a “Generate Hash” block212. During processing associated with block 212, a hash code isgenerated based upon the requesting library. The generated hash code isalso stored in hash library 160 (FIG. 2). During processing associatedwith a “Duplicate (Dup.) Hash?” block 214, a determination is made as towhether or not the hash code generated during processing associated withblock 212 matches any hash code stored in hash library 160, indicatingthat the library to be loaded has already been loaded into VSR 152(FIGS. 2 and 3). It should be noted that hashing as represented inblocks 212 and 214 is only one method of detecting that a duplicatelibrary has been requested. One with skill in the relevant arts shouldbe familiar with other techniques for achieving the same purpose.

If a determination is made, during processing associated with block 214,that the hash code generated during processing associated with block 212does not match the hash of a previously loaded library, control proceedsto a “Load Lib. To VSR” block 216. During processing associated withblock 216, the library for which a load request has been received isloaded into VSR 152. Also stored in VSR 152 and associated with thestored library is the corresponding hash code generated duringprocessing associated with block 212 (see 160, FIG. 2) and an indicationof the particular application that initiated the request that thelibrary be loaded. In this manner, a matching hash code can beassociated with a particular library and one or more applications.

During processing associated with an “Increment Lib Reference (Ref.)Count” block 218, the count (see 158, FIG. 2) of applicationsreferencing a particular library in VSR 152 is incremented. If block 218has been reached from block 216, i.e., the library pointed to hasalready been stored in conjunction with another application; if reacheddirectly via block 214, the library has typically been loaded into VSR152 by a previous application.

During processing associated with a “Point App to Lib. In VSR” block220, the application being loaded is provided a pointer or reference tothe library stored in VSR 152. Finally, once the application has beenloaded during processing associated with block 208 or a pointer to thelibrary has been provided to the requested application during processingassociated with block 220, control proceeds to an “End Load Library”block 229 during which process 200 is complete.

FIG. 5 is a flowchart of a “Stop Application” process 250 that mayimplement aspects of the claimed subject matter. Like process 200 (FIG.4), in this example, logic associated with process 250 is stored on CRSM112 (FIG. 1) in conjunction with ACL 122 (FIGS. 1 and 2) and is executedon one or more processors not shown) of CPU 104 (FIG. 1) and computingsystem 102 (FIG. 1).

Process 250 starts in a “Begin Stop Application” block 252 and proceedsimmediately to a “Receive Stop Event” block 254. During processingassociate with block 254, a request is received by RES 116 (FIG. 1) tohalt execution of an application such as applications 118, 120 and 164(FIGS. 1 and 3). During processing associated with a “Scan for VSR”block 256, VSR 152 (FIGS. 1 and 2) is scanned for indications of anylibraries that have been loaded in association with the applicationbeing halted. As explained above in conjunction with FIG. 2, hash codesare stored in conjunction with indications of the particularapplications associated with the libraries that each hash coderepresents.

During processing associated with a “Libraries (Libs) Detected?” block258, a determination is made as to whether or not the application beinghalted includes any libraries stored in VSR 152. If so, duringprocessing associated with a “Decrement Count” block 260, the count (see158, FIG. 2) associated with the first library detected duringprocessing associated with block 256 is decremented. In the alternative,rather than relying upon a count associated with each library loaded inVSR 152, process 250 may simply determine whether or not any otherapplications are referenced with respect to any particular library.

During processing associated with a “Zero Count?” block 262, adetermination is made as to whether or not the count associated thelibrary currently being processed has reached zero, i.e. indicating thatthere are no currently loaded applications that reference the library.If so, during processing associated with a “Delete Lib From VSR” block264, the library currently being processed is deleted from VSR 152.

Once the library has been deleted during processing, associated withblock 264, or, if during block 262, a determination is made that thecount is not equal to zero, control proceeds to as “More Libs?” block268. During processing associated with block 268, a determination ismade as to whether or not there are more libraries detected duringprocessing associated with block 256 that remain to be processed. If so,processing returns to block 260 and processing continues as describedabove with respect to the next unprocessed library.

Finally, once a determination has been made that no more librariesremain to be processed during processing associated with block 268, orif during processing associated with block 258 a determination is madethat the application being halted does not include any libraries storedin VSR 152, control proceeds to an “End Stop App” block 269 during whichprocess 250 is complete.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

We claim:
 1. A method, comprising; receiving a request to load a firstresource corresponding to an application onto a computing system forexecution; determining whether or not the first resource is identical toa resource loaded in a virtual scope library (VSR); and, if the firstresource is determined not to be identical to any particular resourceloaded in the VSR: load the first resource into the VSR; and directreferences to the first resource in the application to the firstresource loaded in the VSR; and otherwise, if the first resource isdetermined to be identical to the second resource, direct references tothe first resource in the application to the particular resource storedin the VSR.
 2. The method of claim 1, wherein the first resource is alibrary included in the application.
 3. The method of claim 1, whereinthe first resource is a computing artifact associated with theapplication.
 4. The method of claim 1, the determining whether or notthe first resource is identical to any particular resource in the VSR,comprising: generating a hash code corresponding to the first resource;and comparing the hash code to a plurality of hash codes, each hash codeof the plurality of hash codes corresponding to a resource in the VSR.5. The method of claim 1, wherein the method is implemented in anapplication server environment.
 6. The method of claim 1, furthercomprising detecting that the application is excluded from the method;and loading the first resource into the scope of the application ratherthan the VSR regardless of whether or not the first resource isdetermined not to be identical to any particular resource loaded in theVSR or whether or not such a determination is made.
 7. The method ofclaim 1, further comprising: detecting that a particular resource storedin the VSR is not pointed to by any currently loaded application; and,in response to the detecting, deleting the particular resource from theVSR.